A known process for managing structured objects, the objects being mainly complex information, is described in the document: "API to OSI Object Management (XOM) X/Open Preliminary Specification (1990)" published by "X/Open" Jointly with "X.400 API Association." In general, the representation of a private object includes two parts: a generic part which includes header information, and a specific part which concerns the actual or effective representation of the object, and hence of a parameter associated with the object.
In a solution proposed by OSF in the document "API to Directory Services (XDS) X/Open Preliminary Specification (1990)" published by "X/Open" jointly with "X.400 API Association," the actual representation of the private object corresponds to the output parameter, namely the parameter calling up the service to which the objects are to be transmitted (relocated). This service is composed of a set of functions or libraries that can be called up to process the various parameters or objects, and in this service a parameter is a particular structure, so that according to the solution, the representation of a private object corresponds to this structure. This solution has drawbacks, chief among which is that the handling of private objects or parameters is not independent of the definition of these objects, which results in excessive complication of processing and decreased efficiency of the process. Indeed, when a plurality of objects is to be processed, each function used must be applied to each of the objects which corresponds to a particular structure, and the number of operations then quickly becomes excessive.
In addition, still according to this solution, each class is represented uniquely by a description specific to it, and when an object is handled it is necessary to know this class to find out what particular structure corresponds to the object in question. This has the major drawback of a further complication in processing, preventing the various applied functions from being automated.